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I. INTRODUCTION 


A. PROJECT OVERVIEW 


Information is becoming more and more important in the modern days’ day-to- 
day activities, whether they be civilian activities or military activities. The means to 
deliver information has evolved rapidly over the past years. It is true that information 
superiority is becoming another important pillar of any combat type of operations. 

Hence, there is a need for better means of delivering vital information effectively, 
reliably, and on-time, because these can result in life or death in combat situations. 
Traditionally, information is mostly delivered over voice/audio type of systems, in real- 
time or near real-time. However, ‘a picture is worth a thousand words’ as an old Chinese 
saying, hence, it may be beneficial to find a better mean to deliver essential information 
both in traditional voice/audio and in life-interactive-video, in a real-time, or near real- 


time mode. 


In a shipboard situation, such as in a battle group where there are many ships 
traveling together in an open sea. The live-interactive-video conferencing may be very 
useful in communicating with each other among various ships. Combat effectiveness 
and/or logistic support activities may be improved by implementing this type of system 
as a mean to deliver effective, reliable, on-time, and secure information among ships in 


the same battle group or to a different group nearby. The system studied here is the 


packet radio network, which can be used as a backbone or as a medium to deliver the 
information among ships. The system will have a number of nodes or routers installed 
on each ship. And, the information would be sent out by a source, which may be one of 
many ships in the battle group, and then would be routed through these nodes/routers 
installed on the ships, from ship-to-ship until it reaches the desired destination. However, 
the implementations of this system is not only restricted to a sea-based platforms but can 
also be implemented on lands where many nodes/routers are installed on the vehicles, 


which may be either moving or stationary. 
B. INTRODUCTION 


Since our objective is to conduct video conferencing over a packet radio network 
in an economic way, there are two important issues we need to consider. First is what 
type of hardware/software we need to capture, encode/decode, and display acceptable 
video-quality images. And, second is what type of networking supports we need as a 
medium to deliver the data. A practical and economic way to deal with the first issue is 
to utilize the Desk-Top-Video-Conferencing (DT VC) technology due to its low-cost and 
availability in today’s market. A good source for DT VC software/hardware vendors is 
listed by C.E. Hendricks and J.P. Steer [17]. There are many available commercial 
hardware/software packages in today’s market such as Cu-SeeMe, Picture Tel, 
Connectrix, VideoLabs, and etc. But, to deal with the second issue, which is the focus in 
our study, we need to find out what type of radio networks and supports needed to 


accomplish our objective. 


For flexibility and compatibility with the industrial standards and today’s markets, 
our system is intended to support the Transport Control Protocol/Internet Protocol 
(TCP/IP) in many networking environments such as the Wide Area Network (WAN), 
Local Area Network (LAN), the Internet, and the Packet Radio Networks, etc. The 
implementations of our system will probably be in a packet-switching type of networks. 
In 1994, J. Harju, V.P. Kosonen, and C. Li studied the quality and performance of DT VC 
technology in the interconnected LANs environments with TCP/IP carriers [18]. The 
team found out that there is a slight degradation in video quality with increasing number 
of nodes and/or switches. However, our study only focus on the effects of one 
node/router positioned between links with the TCP/IP protocol riding over another 
protocol i.e. the Amateur X.25 protocol (AX.25). The AX.25 protocol 1s widely used in 
the Amateur Packet Radio Networks and has many good features to support delivery of 
data over a radio-networking scheme. Also, during 1995, C.P. Bandy, D.B. Koch did 
some experiments on transmitting stilled images over a low-bandwidth transmission 
system [9]. Their system emulated a packet-radio transmission by using telephone 
modems. The system demonstrated promising results for delivering quality stilled images 
over a low-bandwidth channel. In our experiments, however, we actually transmit data 
packets over a real half-duplex packet-radio channel, and also over a emulated full-duplex 


radio channel. 


There are a couple of reasons which make this project very interesting; the 


flexibility of the system and the possibility of a practical video-conferencing system at a 


very low-cost. This project will require little or no development cost at all, since all the 
technologies, both hardware and software components, are already available at low costs 
in today’s market. The intended system would use mostly Commercial-off-the-Shelf 


products with little or no software modifications to suit the needs. 
C. GOALS 


The overall goal of this project is to study a prototype system which may be used 
to implement an interactive video-conferencing application by using a packet radio 
networking scheme. The long-term goal is to incorporate commercially available video- 
conferencing software/hardware to our packet-radio networking backbone. The video- 
conferencing software/hardware components should support standard protocols such as 
Serial-Line-Interface Protocol (SLIP), TCP /IP, Point-to-Point Protocol (PPP), and etc. 
Hence, we should be able to incorporate these components in some kind of a Network- 


Operating-System (NOS) software which will be used to run on the nodes/router. 


However, the scope of the study in this paper is Only to investigate the 
capabilities, possibilities , and limitations of various components and transmission 
mediums required to support such a system. Hence, the initial study explained in this 
thesis is limited to only study the behaviors of the data being transmitted through the 
amateur radio channel (i.e. the 440-MHz UHF band). The amateur packet radio utilizes 
the AX.25 protocol, and the existing TCP/IP networks implemented through the directly 


connected RS-232 line. In addition, routing behavior of the packets through both 


channels are studied because the overall goal of this continuing project is to conduct 
video-conferencing over the hybrid networks i.e. the packet-radio networks and the 


existing conventional TCP/IP networks (or other wired networks). 
D. APPROACH 


The approach used in this study is to study the channel’s data transmission 
behavior by sending some data using a packet-radio protocol between various nodes 
connected by various types of mediums 1.e. the RS-232 line, the radio half-duplex 
channel, and the radio full-duplex channel. First, the data packets are sent through the 
UHF radio channel with a maximum speed of 19.2 K-baud. Then, the channel is 
improved by emulating it as a full-duplex radio channel. With an emulated channel, to 
study the routing effects, the data packets are routed through both the link, a RS-232 line 
connected between the two nodes running under a Network Operating System (NOS), and 
the emulated-radio full-duplex channel. The application protocol used in this 
experiments is the File-Transfer-Protocol (FTP). Various file sizes are created and sent 
through the channels. Then, the performance parameters, i.e. the time in seconds and the 
average Speed in Bytes/second for each file transfer operation, are recorded. All the 
networking nodes in our experiments are running under the Tampa Network Operating 
System (TNOS), which is just a version the original KA9Q Network Operating System 


(KA9Q NOS), written by Phil Karn [6]. 


This thesis is organized into six major chapters. The first chapter, Chapter I, 
describes the project in a big picture, including approach used and objectives of our 
studies. Chapter IT gives the readers some backgrounds needed to understand 
fundamental technologies in this field; the packet radio and networking. Chapter III 
explains the experimental set ups, used in our study. Then, the results are explained in 
Chapter IV. Chapter V discusses the results and compare them with other experiments. 


Lastly, Chapter VI concludes the experiments and recommends future research efforts. 


Il. BACKGROUND 


A. PACKET RADIO BACKGROUND 


Amateur Packet Radio 1s an on-going development technology in the amateur 
radio world. Both the software and hardware are currently being developed and tested by 


the amateur packet radio enthusiasts. 
ie History of Packet Radio 


The data packet technology was developed and put into practical use during 
1960’s with the ARPANET project [1]. However, the amateur world of packet radio did 
not benefit from the development of this technology until during the 1970’s. The first 
amateur packet radio operations began in Montreal, Cadana, and followed by the 


Vancouver Amateur Digital Communication Group (VADCG) [1]. 


In today’s radio mateur world, for some simple reasons; practicalities and 
economics, the packet radio technology is increasingly becoming popular. Packet radio 
contains wide varieties of applications for amateur radio broadcast ranging from near 
real-time converse mode, remote telnet, file transfer service (FTP), simple mail transfer 
protocol (SMTP), or even, transferring stilled images in a near real-time environment. 
These applications are possible because this type of technology, through a ‘free’ amateur 
radio band, is able to provide flexibility and capabilities of conventional digital 


communication networking at an incredibly low-cost. 


For an example, an amateur packet-radio operator can sent the information 
through the amateur radio network to a node at may be 2500 miles away with little 
investment in the equipment. The minimum components of the equipment to conduct 
such operations are the terminal node controller (TNC), a computer or a terminal, and a 
2-meter transceiver. These equipments are already available in the market at low costs. 
In this experiment, the PC computers under DOS are already available, hence, the only 
additional equipments needed are, the TNC, the transceiver, and the software to transmit 


radio signals in a network environments. 


Further more, there are still a few more reasons that make packet radio more and 
more popular; transparency, error correction, and automatic control [1]. Transparency is 
provided by the packet radio technology to the end users. Each user make a connection to 
the other station, then the data input by the user will be sent to appear at the destination 
node automatically. This is done by the Terminal Node Controller (TNC). The TNC 
receives input data through the interface from the data input terminal i.e. the computer 
running a software packet, or a dum terminal, then, it automatically divides the data into 
packets and put the overheads onto each packet (usually an AX.25 protocol overheads). 
The TNC, then, keys up the transmitter and send the packets through the radio wave 


carriers i.e. UHF/VHF, or microwave, etc. 


In additions, the TNC hardware also provides automatic error detection scheme. 
If the information is corrupted during transmission through the medium, it will 


automatically send a request for retransmission to the transmitter. Hence, only correct 


data are received, stored, and displayed to the operator. A typical packet radio station 


with various components and interfaces are shown in Figure 1 below. 
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Figure 1: A Packet Radio Station [1] 


Ground 


One of the packet-radio features that makes the technology very interesting is that 
it has a shared channel capability [1]. This means that many users can share the same RF 
channel at the same time. This capability is possible because of the utilization of a 
special protocol designed for amateur packet radio called the AX.25 protocol (the 
Amateur X.25 protocol). The AX.25 protocol identifies the channel accessibility by 
using the TNC to sense if any station is transmitting, and, if it is so , it will wait until the 


channel is free. This scheme is called the CSMA or ‘Carrier Sense Multiple Access’. 
ap The AX.25 Protocol 


The AX.25 protocol, or the Amateur X.25 protocol, was developed based on the 


conventional X.25 protocol, used widely in the wired network. The X.25 protocol is 


modified due to its own lacking of some necessary features which are needed in the 
wireless radio types of operations. The AX.25 adds a digipeater field for extended range 
by other stations repeating the packets over and over again until the packets reach the 
destination [1]. Also, the AX.25 protocol’s packet format adds the sender’s callsign and 
the receiver’s callsign to every packet, which is very useful for identification purposes 


[1]. 


The AX.25 is a link-layer protocol that is able to support various types of 
communication links. According to the OSI model [3], the AX.25 link-layer is just right 
above the physical layer, hence, it is independent of higher level and can support many 
communication schemes regardless of the existence of many other higher levels [2]. The 
independence of its link layer from higher-level layers is because it already have 
capabilities for reliable transfer of information across the physical link layer 1.e. 
synchronization, error control, and flow control. These capabilities are minimum 
requirements for establishing a link and are providing the amateur radio operator with a lot 
of flexibility due to small overhead losses required by higher-layer OSI models. Typical 


implementation of the OSI model is as shown in Figure 2. 
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Network Layer Network Layer 
Data Link Layer AX.25 Link Layer Data Link Layer 
Physical Layer Radio Link Physical Layer 


Figure 2 : The OSI Model [3] 





This protocol, the AX.25, also follows the recommendations of the Consultative 
Committee on International Telegraphy and Telephony X.25 (CCITT X.25) [3], but it is 
different in the extended address field, designed to support operations in a radio 
environment [2]. In addition, the AX.25 also adds an Unnumbered Information frame 
i.e.a UI frame. The shared-RF channel is also implemented in the AX.25 protocol, 
following the CCITT recommendation Q.921, supported by the distinguished and 


extended address field [2]. 


The improved features of the AX.25 protocol allow the protocol to support more 
than one link layer per communication device, provided that the device is able to handle 
more than one link establishment, and also allows the protocol to be able to operate well 


in either ‘half-duplex’ or “full-duplex’ radio environments [2]. 


Once the data from the higher level are processed and sent to the lower level 
before passing it to the physical level (i.e. the link layer), the data are divided into small 
blocks of information called ‘frames’, which are composed of various smaller subsections 
called ‘fields’. There are typically three types used by the AX.25 protocol; the 
Unnumbered frame (the U frame) , the Information frame (the I frame), and the 
Supervisory frame (the S frame). The constructions of the three types of frames are 


shown in Figure 3. 


Flag Address Control FCS Flag 
~OULITIO «(f= 112/560 bits 8 bits L6 bits 01111110 


U-frame and S-frame structures 





Flag Address Control PID Information FCS Flag 
01111110 112/360 bits _ $bits 8 bits N*8 bits 16 bits 01111110 


I-frame structure 





Figure 3: The U, S, and I Frame Formats [2] 


From the above frame formats, there are many field types inside the frames, and 
each is responding to specific function. The flag field is 8-bit or 1 octet long and has a 


unique specific bit sequence -- ‘01111110’ (or, 7E Hex.). This specific bit sequence is 
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put at the beginning and the end of a frame to indicate that the information between the 
two flags is some kind of a frame. Hence, this unique bit sequence cannot appear 
anywhere else except in the flag fields. The mechanism that guarantee the non- 
reappearance of the unique flag bit sequence is called the ‘bit stuffing’ operations. Bit 
stuffing is done by monitoring the transmitted frame to see if there is any five 1’s in 
sequence, if there is, then a ‘QO’ bit is stuffed right after the five ‘1’ sequence. And, at the 
receiving DXE, it will utilize the same mechanism to monitor the frame’s bit sequence, 
but, this time, instead of adding another ‘0’, it will discard any ‘O’ bit right after the five 
consecutive ‘1’ sequence. This operation guarantees that there will not be any flag field 
pattern appearing anywhere inside the frame which may cause confusion and errors to the 
receiving DXE. After the beginning flag field, there is an address field which contains 
two sub-fields indicating both the source and destination addresses of the specific frame. 
In additions, if there are repeaters for the purpose of extended range along the way 
between the source and destination, the addresses of the repeaters are also encoded into 
the address field. Once, the frame reaches the destination, it may be interrupted by 
various sources of interference along the path, which may cause the frame errors. Hence, 
the AX.25 protocol provides mechanisms for error checking in the FCS field. The FCS, 
or the Frame Check Sum field contains a 16-bit sequence, and is calculated 5, both the 
receiver and the transmitter. The identical FCS fields on both ends indicate that there are 


no error, otherwise the frame is corrupted by the medium if the FCS fields are not 
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matched. In this case, the receiver may discard the error frame and send a request for 


retransmission. 


The other field inside the frame which is very important is the control field. It is 
used to identify what type of frame it is 1.e. either the U-frame, the I-frame, or the S- 
frame. The Information-Transfer frame, or the I-Frame, is responsible for transferring of 
the actual data contained in its information field [2]. To identify all the I-frame from 
other types, the bit # 0’s in its control field is set to zero. The I-frame’s control field also 
contains the sender’s send sequence number, N(S), which is the send sequence number of 
the current frame. This number is updated just right before the frame is being 
transmitted. The sender’s device has an internal send state variable to keep track of the 
next Pens number of the next frame which is to be transmitted. And, this internal 
variable is used for updating the send sequence number prior to transmitting the frame. 


The I-frame’s control field is encoded as follows. 


Control Bit Sequence Number 
246i Fre 


Mm —__> ll 
N(R.) P N(S) 0 


Figure 4 : The I-Frame’s Control Field Format [2] 
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The N(R.) is the received sequence number which exists in both the I-Frame and 
the S-Frame. This number implies the complete and proper operations of the received 
frames up to the N(R.) -1 frame. Also, same as updating the N(S), the N(R.) is also 
updated accordingly to the device’s internal received state variable, in which, the variable 
contains the next expected number of the incoming frame. The P-bit is actually the P/F bit 
(Poll or Final Operations). The Poll mode is used to request an immediate reply to a 


frame, and, the reply to this specific frame is done by resetting the Poll bit to a Final bit. 


Other than the I-frame, the S-frame is also playing an important role in 
establishing and maintaining the links. The S-frame provides many valuable services 
such as acknowledging, requesting retransmission in case of errors , and providing link- 
level window control [2]. The S-frame is distinguished from others by setting bit # 0 of 
the control field to one, and bit # 1 to zero. In the S-frame’s control field, there are a few 
encoding mechanisms which are really important in its operations; they are RR, RNR, 
and REJ. The RR is ‘Receiver Ready’ used to indicate that the sender of the RR is ready 
to receiver more I frames. It also implies that the frames up to N(R.) -1 is properly 
received and acknowledged. The RNR is ‘Receiver Not Ready’, in contrast to the RR, it 
is used to indicate that the sender’s device is busy and not being able to receive more I 
frames at that time. And also, the I frames which are indexed higher than N(R.) - 1 may 
be lost or unacknowledged. The REJ is ‘Reject Frame’ which is used to indicate that the 


frame may be duplicated or is out of sequence, and it is rejected by the receiver. The 
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REJ is also, at the same time, used to request retransmission of the frames starting with 


the frame indexed with N(R.) and above. 


Another interesting frame format used for the AX.25 protocol is the Unnumbered 
frame format (the U-frame). This type of frame allows more control of the link in 
additions to the typical Supervisory frame (S-frame). The U-frame is also responsible for 
establishing and terminating the link connections, and it also allows some other unusual 
flow operations [2]. The U-frame’s control field is used to indicate either the frame is a 
command or response frame. There are six important encoding schemes for its control 


field formats, they are the SABM, DISC, DM, UA, FRMR, and the UI. 


The SABM is the “Set Asynchronous Balanced Mode’ command. It is used to set both 
DXE’s into an asynchronous balanced mode [2]. In the shared-RF channel with the 
AX.25 protocol, the DXE is used to replace both the master device 1.e. the DCE , or the 
Data Communicate Equipment and the slave device 1.e. the DTE, or the Data Terminal 
Equipment. This is because the AX.25 treats both devices as equal importance, not 
unequal as in the classical master/slave scenario for the typical unbalanced mode of 
operations. To accept the SABM request and confirm the setting of an Seaton 
balanced mode, the DXE must issue the UA (Unnumbered Acknowledge) at the earliest 
opportunity. Once the link is established, if any DXE wants to terminate the link, it, then, 
has to issue the DISC command (the Disconnect Command), and wait for the UA 
response from the other DXE before it enters the disconnect state. When the received 


frame cannot be processed and the retransmission of that specific frame will not solve the 
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problem, the DXE will response by sending the FRMR (Frame Reject Response) to the 
sender containing the information field that indicates the cause of rejection. This scenario 
usually occurs when the received frame does not contain the FCS (Frame-Check-Sum) 
field, or from many other causes. In some cases, one of the DXE may try to send other 
frames other than the SABM or the UI while they are in the disconnected mode. Then, 
the DXE will response to the sender with the DM (the Disconnected Mode) response 
telling the other DXE that it is still in the disconnected mode and also requesting a set 
mode command. Another case that the DXE issues the DM response is when it receives 


the SABM mode and is not yet being able to establish a connection at this time. 


There are some cases when the DXE wants to send frames bypassing the link 
layer ‘s normal information flow control. The UI (Unnumbered Information) frame 
allows the DXE to do just that. The UI frame contains the PID (Protocol Identifier) and 
the information field which is independent of normal flow control, and, hence, it can be 
passed back and forth freely [2]. But, since the UI frames are unnumbered and above the 
normal flow control, they will not be acknowledged by the receiving DXE, this causes 
unrecoverable UI frames when lost. However, the UI frame can request an indirect 
acknowledgment by setting its P-bit to ‘1’. The set P-bit causes the receiving DXE to 
response with a DM frame while in the disconnected mode and with either a RR ora 


RNR frame while in the information transferring state. 
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B. PACKET RADIO NETWORKING 
1. Network Operating System (NOS) 


Packet radio technology is a way to send information in some sort of packet 
format, which encapsulates data with protocols and source/destination addresses, 
including some information regarding the path along the way. The real benefit of packet 
radio technology is that the information can be send to the destination by using a 
networking scheme, giving the operators more flexibility, efficiency, and effectiveness in 
delivering the information. The software package that supports the implementations of 
packet radio technology in a networking scheme is called the Network Operating System 
(NOS). There are many Network-Operating-System (NOS) software packages available 
today to support the implementations of this kind of technology such as the NET/ROM, 
KA9Q NOS , WNOS, JNOS, and TNOS, etc. However, many of the software packages 
are based on the original KA9Q NOS, written by Phil Karn [6], but with some 
modifications and enhancements. The main attraction for the NOS is that it supports an 
internationally agreed standard, which gives it the ability to operate in many existing 
networks and interfaces such as the packet radio networks, the telephone lines, the Local 
Area Networks, and the TCP/IP networks (1.e. the Internet) [5]. This makes the NOS as 
a very powerful communication tool because information can be routed in both the 


conventional wired-networks and the more flexible radio-networks. 
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The flexibility of the NOS comes from its supports of many protocols such as the 
ARMPnet (the Amateur TCP/IP Packet Radio Networks), NET/ROM, and the AX.25. 


The packet format is as shown in Figure 5. 





Figure 5 : NOS Multi-Protocol Frame Format [5] 


From the format above, hence, there are at least three routing schemes 
possible by the NOS; AX.25 routing, NET/ROM routing, and TCP/IP routing. The NOS 
has commands to set up routing for these protocols. The ‘ax25 route add’ command can 
be used to set up a digipeater routing scheme, which will be explained later. The 
NET/ROM and the TCP/IP routing schemes can be accomplished by the NOS commands 


‘netrom route’ and ‘route’ [5]. 


2: Networking Schemes 


As mentioned earlier, packet radio is flexible and very useful because the 
information can be efficiently routed through various networks to reach the desired 
destinations. There are many networking schemes used in packet radio technologies 
such as the digipeaters, KA-nodes, NET/ROM, ROSE, TCP/IP, and the TexNet [1]. A 
digipeater is simply a repeater. It is only used to extend the range of the packets by re- 


transmitting any packet that is addressed to itself to the next digipeater, if any, or to the 
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destination node. The downfall of the digipeaters is that the source station has to wait for 
the acknowledgment from the final destination node. If there are many digipeaters along 
the path, it may waste precious time. One improvement is made over this scheme by 
allowing each digipeater to be able to acknowledge the received packet, hence, the 
acknowledge is executed at each link instead of the whole path. This makes the transfer 
of information a Ilittle more robust than just a simple digipeater scheme. This scheme is 


called the ‘KA-nodes’ type of operations. 
a. NET/ROM 


The first two schemes, mentioned earlier, are not really a real networking 
type of operations. The first attempt to set up a networking scheme is by using a local 
station connected to the user, then, the local station can connect the user to the others 
through that local station. And, if the destination 1s out of the local range, then, the 
NET/ROM local station will try to make a connection to another local station nearby 
again and then again, if necessary, until it can reach the desired destination. The local 
station, in this case, 1s called the NET/ROM station. The NET/ROM 1s a firmware 1.e. 
the software installed on a chip [1], which is responsible for routing and making 
necessary connections. This method makes the information transfer more efficient since 
each user is only connected to its own local station instead of connecting to a distant 


destination. 
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b. ROSE 


Another routing scheme other the NET/ROM, ROSE uses a static routing 
table [1]. The ROSE protocol maintains a static list of nodes that it can reach. And, if 
any user wants to utilize the list maintained by the ROSE switches along the way, then, 
he or she must specify the addresses of the ROSE switches in their digipeater fields until 
the packets can reach the other user maintained by a final ROSE switch. The trade-offs 
between the NET/ROM automatic routing scheme and the ROSE’s static routing scheme 
is the reliability and maintenance. The ROSE protocol is more reliable because each 
node maintain a specific list that it can reach for sure, unlike the NET/ROM which may 
try to reach an reachable node. However, the NET/ROM can update its list automatically 
as a new node makes a contact with the NET/ROM station, without having to manually 
update the routing list. But, when conditions change and some nodes which are no 
longer reachable, the NET/ROM station will falsely still maintain those nodes as 


reachable ones. 
C. TCP/IP 


Another popular protocol is the TCP/IP protocol (Transport Control 
Protocol/Internet Protocol) which is supported by the various packet radio technologies 
such as the original KA9Q NOS (KA9Q Network Operating System), JNOS, and the 
TNOS (Tampa Network Operating System). The TCP/IP allows flexibility and 
compatibility in routing the packets through various existing networks. Also, there are 


many facilities already existed in the TCP/IP protocol such as FTP, Telnet, SMTP 
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(Simple Mail Transfer Protocol), and NNTP (Net News Transfer Protocol), etc. The 
implementation of TCP/IP routing scheme into the amateur packet radio world is by 


having the AX.25 rides on the top of the TCP/IP protocol. 


When the AX.25 is integrated with the TCP/IP networks, the NOS 
supports such integration by using the TCP/IP links as a wormhole to route information. 
The command that is supported by the NOS to do the wormhole routing is the ‘AXIP’ 
command which implies ‘AX.25 over IP networks’. This command can also be used 
with the ‘attach’ command to make the NOS recognizing the interface. The ‘attach axip 
...” command creates a RFC1226 compatible AX.25 frame encapsulator for transmission 
of the AX.25 frames over the internet [6], which makes the IP wormhole routing 


possible. The AX.25 wormhole routing over IP networking scheme is shown in Figure 6. 
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Figure 6 : AX.25 over TCP/IP Links [5] 


Ze 


Til. EXPERIMENTAL SET-UPS 


Since it is desirable to study some data-transfer characteristics and performance 
over different channels. A test bed with a radio channel was set up in the laboratory. 
Hence, several communicating nodes were set up with various communicating 
mediums between them. Firstly, we want to study the data-transfer behaviors over a 
simple radio channel. Two nodes connected with a half-duplex radio medium were 
used. Secondly, we want to improve the performance of the data-transfer measured 
from the first set-up, so, an emulated full-duplex radio channel with optimum allowable 
hardware configurations was used. And, thirdly, we want to study the routing effects 
across the node, so, we incorporated an additional node and perform data-transfer 
operations across the router. However, some specific hardware and software 


components needed to be correctly configured and interfaced are described here. 
A. THE TNOS SOFTWARE 
1. An Introduction to TNOS 


TNOS, or the Tampa Networking Operating System, is a multi-threaded program 
that is able to handle the TCP/IP standard protocol in a radio environment, and, was 
written by Brian A. Lantz [4]. The software was developed from the original version 


KA9Q NOS, and, has many foundations and many features alike, but, with additional 


24 


enhancements. To make the explanations simple, we will be referring to NOS instead of 


the TNOS because NOS is more general and original. 


NOS is a complex software package that supports most of the widely used 
communication protocols over the internet such as the TCP/IP, TELNET, FTP, SMTP, 
and over the packet radio network such as AX.25, NET/ROM, and PBBS mail [5]. The 
NOS can act as a gateway, a router, or simply a digipeater, and is platform-independent, 
which means that all these protocols can run on any operating system such as the PC, 
UNIX/XENIX, DEC VAX on VMS, or a Spare workstation on SunOS, etc. [5]. Since it 
has an internal multitasking operating system, the software package can act 
simultaneously as a client, a server, and a switch for the three set of the protocols i.e. the 
TCP/IP, AX.25, and the NET/ROM [6]. This means that while the local user is 
accessing other systems through the network, other users in the network can also, 


simultaneously, utilize the local system’s resources [6]. 
2. Installing the TNOS 


In our experiments, the TNOS is running on a PC platform, under Windows 95 or 
Windows 3.11. The reason that we run the TNOS.EXE under Windows 3.11 and 
Windows 95 is because the software needs a DPMI (DOS Protected Mode Interface), 
which already exists under the Microsoft Windows 3.11 &95 [7]. The DPMI is needed 
because it has capabilities to collaborate between the multitaskers and other Protected 


mode utilities [7]. The TNC is interfaced to the PC through a serial port i.e. the 
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asynchronous COM ports; COM1-COM4. The TNC is operating in a KISS mode which 
means that it simply passes all the information from radio to be processed by the TNOS 


software package inside the PC. The overall picture is as shown in Figure 7. 
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Figure 7 : The TNOS Software Interfaces [5] 





The TNOS software package is distributed freely through various internet sites 
such as at the ‘ftp://ftp.lantz.com/tnos/current’ or at the “ftp.ucsd.edu’ in the 
‘/hamradio/packet/tcpip’ directory [4]. There are a couple of files needed to be 
downloaded; the base supported file and the execution file (TNOS.EXE). The supported 
file is in a ‘.ZJP’ format, and it can be decompressed by using a free unzip shareware, 1.e. 
the PRUNZIP.EXE with the ‘-d’ option, which will put all the decompressed files into 
their corresponding directories. Once the TNOS.EXE file is downloaded into a platform 
i.e. a PC in our set up, then, its autoexec.nos is needed to be configured to meet specific 


needs for each user. When the TNOS.EXE is running, at first, 1t will automatically look 
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for the ‘autoexec.nos’ file which should contain all the configuration information needed 
for operating the network correctly. And, if the file does not exist, the user, then, has to 
input the detailed configurations manually line-by-line during the executing program. 


The example of the autoexec.nos is given in Appendix A. 
3. I/O Device Interfacing 


There are some important configurations needed to be carefully set up before we 
can operate the software correctly for our data-transfer experiments; these are the ‘attach’ 
command, the ‘ftpusers’ file, and the ‘domain.txt’ file, etc. These files are also given in 


Appendix A. 


In our experiments we want to utilize the FIP session supported in the TNOS 
software to transfer the files of various sizes, and then study the file transfer 
characteristics through various channels and environmental settings. To accomplish this 
purpose, the TNOS software must be able to interface with the PC’s I/O devices through 
their corresponding device drivers. In our case, we use the PC’s asynchronous COM 
ports as our I/O devices. The TNOS software package can acknowledge the COM ports 
through its ‘attach’ command. The attach command allows the TNOS — to 
interface to various hardware device drivers such as the asynchronous COM ports, the 
Ethernet, and the Modem, etc. [6]. The attach command loads up the specific device 
driver through its corresponding device’s I/O port address. Hence, the attach command 


will need to know the COM port’s base I/O address, including its interrupt request level 


Zi 


(IRQ), the desired protocol to be used through that specific COM port, and some other 


important parameters such as the buffer size and the packet length. 
4. Setting Up the FTP Session 


Another important set-up before we can utilize the FTP protocol in our 
experiments is the ‘ftpusers’ file. Once the TNOS software is correctly installed, this file 
is under the ‘../etc/’ directory. It maintains the allowed list of user names and their 
corresponding passwords, including their allowed directories and types of operations i.e. 
‘read files’, “create new files’, or ‘write/delete existing files’ [5]. Also, given a domain 
name, and the user is trying to make a connection to another station, the software will 
need to know the IP address of such station. TNOS deals with this matter by having a 
look-up table to translate the desired domain names into their corresponding IP addresses 
contained in the ‘domain.txt’ file which can either be automatically updated, by the 
software itself, or, manually updated, by the user. Once the software is installed, this file 


is under the *../spool/’ directory. 
a Setting the TNC Parameters 


In our experiments, the TNC is needed to be set into the KISS mode. The TNOS 
has the ‘comm’ command that is able to set up the TNC to do such thing. peters 
switching the TNC into a KISS mode, to prevent unrecognized parameter-settings, the 
TNC should be reset into its default values before changing other parameters to other 


settings. The string ‘reset’, sent directly from TNOS to the TNC, will result in resetting 
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the TNC. The command that 1s able to send strings directly to the TNC 1s the ‘comm’ 
command, i.e. the communication command. To switch the TNC into the KISS mode, 


the strings ‘int kiss’, 1.e. meaning ‘interface kiss’, must be sent to the TNC. 


Other than the ‘comm’ command, there is another command that is able to 
communicate directly with the TNC and set the TNC’s parameters to different settings. 
The TNC parameter settings can be changed by executing the ‘param’ command, Le. the 
parameter command. The TNC’s TXDELAY, PERPIST, SLOTTIME, and many other 


parameters can be set by using this command. 


In our experiments, the TNC is operating under a KISS mode (Keep-It-Simple- 


Stupid Mode). The frame format at each interface is shown in Figure 8. 
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Figure 8 : The KISS Frame Format [5] 
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As shown by the in Figure 8, the KISS TNC simply passes all the data to the PC 
through the asynchronous port for the data to be processed at a higher level [5]. Hence, 
the TNC is only responsible for the RF channel access and frame conversion. The TNC 
controls the RF channel access properties by settings its two parameters; the ‘PERSIST’ 
and the ‘“SLOTTIME’. The RF channel is accessible when the TNC does not detect any 
carrier on the air. Then, it will start a timer with the length of time specified by the user 
through the ‘SLOTTIME’ parameter. Once, the timer is out, then, the TNC will generate 
a random number between 0 - 255. The random result will be compared with the user’s 
specified ‘PERSIST’ parameter. If the generated random number is less than or equal to 
the user’s setting PERSIST value, it will then key up the transmitter and transmitter the 
packets out over the channel. For frame conversion, the TNC simply puts or strips off the 
frame’s start & finish characters 1.e. the ‘“FEND’ characters. All the decisions regarding 
routing, access permission, digipeating and all other higher level protocols are made at a 


higher level in TNOS, not at the TNC level. 
B. THE HARDWARE 
1. The Terminal Node Controller (TNC) & The D4-10 Transceiver 


The Terminal Node Controller (TNC) and radio used in our experiments are the 
Katronics Data Engine and a 10- watts high-speed transceiver 1.e. the D4-10 UHF Wide- 
Band Transceiver [19]. The transceiver operates in a high-speed packet radio mode on 


the UHF band (430.55 MHz). When combining the D4-10 transceiver with the 
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Katronics Data Engine, there are two possible speeds; the 9600 baud rate or the 19200 
baud rate [19]. The Data Engine has an internal DE19K2/9K6 modem which is capable 
of generate the ‘data carrier detected (CD)’ signal from the received data stream, and is 


very useful for many of its operations [19]. 


There are quite a few fundamental mechanisms concerning radio operations which 
needed to be well understood before we can operate the radio channel efficiently; the 
‘Push-To-Talk’, the “TXDELAY’, and the ‘Carrier Detected (CD)’. In general, when a 
typical HAM radio operator wants to transmit a radio signal, the operator must push the 
transmitter button and then talk. This operation is called the ‘Push-to-Talk’ operation, 
and is executed whenever the operator wants to modulate the data and transmit the signal 
over a radio channel. However, before the signal is transmitted in the form of a radio 
wave through the air, the transmitter must be fully powered-up to its maximum power 
setting to achieve its maximum signal strength. The time delay during powering-up the 
transmitter is called the transmitting delay (TXDELAY). Once, the signal is transmitted 
and is arriving at a receiver, the receiver will have some delay-time, called the “Squelch 
Time’ [19], before it acknowledges the presence of the received signal and, then, 
produces a CD signal. This delay-time should also be accounted for in the TXDELAY 
setting. Once, the signal 1s detected, then the CD will be pulled-down low by the 
transceiver and output to the TNC to start demodulating the signal [19]. However, the 
CD may be generated by the firmware inside the TNC instead, which 1s a feature in all the 


Katronics Data Engines [19]. 
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As mentioned earlier, the TNC in our experiments, operates in a KISS mode 
which allows all the higher-level protocols to be processed in the TNOS software. 
However, some hardware parameters inside the TNC must be optimally set up to achieve 
a maximum performance. These hardware parameters are the TXDELAY, 
PERSISTENCE, SLOTTIME, modem (half or full-duplex), and KISS [19]. Setting 
these parameters can largely affect the data-transfer performance of the RF channel. 
Generally, the smaller the TXDELAY, the better the performance due to less wait-time 
for the sender before keying-up its transmitter. Also, the larger the PERSIST value, the 
faster the data transfer because there is more chance for the sender to key up the 
transmitter. However, the receiver’s buffers may be flooded, if the PERSIST value is set 
too high because the resceiver and its corresponding Central-Processing-Unit (CPU) may 
not be able to process the received data fast enough. Hence, there may be some lost 
characters due to overflowing the buffers. The lost characters will cause transmission 
errors and requesting for retransmission. The effect of data retransmission is negative to 


the data transfer performance of the channel. 


Another important hardware parameter setting is the SLOTTIME. The 
SLOTTIME 1s the time period between the PERSIST algorithms to generate a random 
number. The SLOTTIME should be long enough to allow the packets to be processed at 
both ends i.e. the transmitter and the receiver, including the round-trip-estimated time on 
both ends. Again, intuitively, the smaller the SLOTTIME, the more frequently the 


transmitter makes its decisions whether it wants to transmit the packets or not (by 
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generating a random number and compare with the setting PERSIST value). And, 
further more, there is another TNC hardware parameter setting, called the ‘modem’, that 
can be set to enhance performance of the data transfer process over a radio channel by 
setting at full-duplex. If the FULLDUP is turned on, then the TNC will operate in a full- 
duplex mode. It means that, between the two communicating nodes, they will not have to 
wait for the channel to be free before anyone of them can transmit or receive 
acknowledgment data since they both have different channel of their own. Unlike 
operations in the half-duplex environments, with full-duplex environments both 
communicating nodes can transmit and receive data at the same time, which really 
improves the performance of the data transfer. In real life, for a full-duplex radio, there 
may be two frequencies needed for such operations. Also, when the operator wants the 
TNC to process some low-level protocols supported by its built-in firmware, not as just a 
dum hardware passing all the information to the TNOS at a higher level, the TNC can be 


commanded to exit out of a KISS mode by using the ‘KISS’ command. 
ae The PC and its FIFO 


The three PC’s used in our experiments are IBM compatible with various Intel 
CPU’s; the 66-Mhz 486DX, 200-Mhz Pentium™, and the 75-Mhz Pentium. The two 
PC’s with the Intel 66-Mhz 486DX CPU and the 200-Mhz Pentium™ CPU are running 
under Windows 95. These two PC’s, in our experiments, are named PC # 1 and PC # 2, 
consequently. The other PC with the Intel 75-Mhz Pentium CPU is running under 


Windows 3.11, which is named PC # 3 in our experiments. 
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There is a very important issue in putting various PC’s together to work in a 
networking environment through their asynchronous I/O devices s i.e. modem and serial 
interfaces, which is the buffer size supported by the UART chip at their corresponding 
FIFO’s ( First-In-First-Out buffer). The UART is an abbreviation for ‘Universal 
Asynchronous Receiver/Transmitter’ [7]. The buffer mismatch may result in difficulties 


in transferring data through the asynchronous device due to lost data. 


The performance of the UART chips depend on how fast they reset after an 
interrupt request for data transfer from the CPU. The original National Semiconductor 
8250 chip, with a l-byte buffer, resets in 1000 ns. [7], which is good enough in the old 
days where the CPU was not as fast as today. If the UART chip does not reset before the 
next CPU’s interrupt request, there may be problems. However, with faster and faster 
CPU in today’s market, the UART must have much faster reset time to satisfy the CPU’s 
interrupt speed. The UART chip store data on in its buffer and wait for the CPU’s 
interrupts to transfer data. The newer 16450 UART chip, also with 1-byte buffer, has 
some speed improvement — 200 ns. reset time [7]. This helps out a lot when working 
with faster CPU such as the 486 CPU and later. But, again, the new problems occur with 
increasing multitasking environments, such as those running under Windows 3.11 and 
Windows 95, and, with higher performance (i.e. speed) of data transfer device — 9.6 
Kbaud rate and 19.2 Kbaud rate, etc. The problems originate when the 1-byte buffer is 
full and the UART chip is not able to transfer data to the CPU at that time because the 


CPU is processing other task (i.e. multitasking environment), and there is more data 
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coming. Hence, the UART chip may be forced to discard the data, which, in our 
experiments, may cause some lost characters and requests for data retransmission. The 


overall result is a slower speed for the FTP operation. 


However, the newer UART chip, the 16550 chip, solves this problem by adding 
more buffers to store data to be transferred at later time. The 16550 UART chip has a 
16-byte buffer, which can be set to any size between 1 16-byte size in the software 
(under Windows 95 in our experiments). But, the interfacing between these PC’s with 
different buffer sizes is a problem because the 1-byte buffer may be overflowed and, 
hence, causes lost characters. In our experiments, PC # 1 has a 8250 UART chip, and 
both PC # 2 and PC # 3 have 16550AF UART chips. We solved the buffer mismatch 
problem by setting the 16550AF UART chip to operate with only 1-byte buffer for both 
receiving and transmitting. This 1-byte buffer setting works well and solves the buffer- 
overflowed problem in our experiments. The TNOS software provides a mean to check 
the asynchronous device status through the ‘asystat” command. By using this command, 
if there 1s a buffer-overflowed situation, then, the number of lost characters will show up 


under the display ‘hw over’ 1.e. meaning ‘hardware overflow’. 
3 Hardware Interfaces & Low Level Protocols 


NOS (including TNOS) supports many interfacing devices such as serial ports 
(COM1-COM4), Modem Control, Ethernet Adapters, Clarkson Drivers, PACcom PC100, 


DRSI PCPA 8530 driver, High Speed DRSI/HAPN driver, Semi-port and Multi-port 
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KISS TNC, and etc. [5]. Also, there are a number of protocols supported by NOS to 
interface with such devices; for examples, the KISS protocol for TNC control, the SLIP 
protocol and the PPP protocol for serial-link point-to-point telephone links, the NRS 
protocol for NET/ROM control, and the Ethernet and ARCnet protocols for Ethernet 


adapters. 


The SLIP (Serial-Link-Internet-Protocol) protocol can be used between a poit-to- 
point type of operations. The SLIP does not need a link header since the connection is 
only point-to-point. The IP datagrams are simply encapsulated with the SLIP frames 
[6]. Also, another useful protocol, used for Point-to-Point links, is the PPP protocol. The 
PPP encapsulates the datagrams in an HDLC-like frame, which 1s an Internet standard 
that is compatible with the CCITT (Consulative Committee in International Telegraphy 
and Telephony) standards [3,6]. HDLC is an abbreviation for ‘High-level data link 
control’, specified by the ISO 3309, 4335 [3]. The HDLC frame contains, consequently; 
an 8-bits flag field, ‘at least’ 1-octet address field, 8- or 16-bits control field, variable- 
length information field, 16- or 32-bits Frame-Check-Sequence (FCS), and again, lastly, 


the 8-bits flag field. 


In our experiments, we use the KISS-mode TNC to interface with the PC using 
the AX.25 protocol to communicate with the other nodes. Also, we interface the two 


PC’s together by using the AX.25 protocol over the asynchronous I/O devices. 
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IV. RESULTS 


Since we want to study some data-transfer characteristics and performance over 
various channels, including their interactions with a radio channel, hence, there are some 
communication nodes needed to be set up with the desired mediums between them. 
Firstly, to study the data-transfer behaviors over a radio channel, we set up two nodes 
connecting with a half-duplex radio medium. Secondly, to improve the performance of 
the data-transfer from the first set-up, an emulated full-duplex radio channel with 
optimum allowable hardware configurations was used. And, thirdly, to study the routing 
effects across the node, so, we incorporated an additional node and performed data- 


transfer operations across the router. 
A. DATA PACKETS 


By using the ‘trace’ command, the data packets can be seen and recorded for later 
analysis. The ‘trace’ command enable the software to trace all the packets passing 
through the asynchronous I/O device (1.e. at the local COM port). The maximum 
transfer unit (MTU), a hardware dependent parameter, used for the data packets in our 
experiments is a 512-bytes size (specified by the attach command). Hence, each packet 
will have 472 bytes of data at the TCP level, because the TCP/IP cost an overhead of 40 
bytes. The level hierarchy from higher-to-lower levels are TCP level > IP level > 


AX.25 level > KISS level, as shown in Figure 9. 
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Figure 9 : Data Packet Transfer 
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The data-packet transfer example is a typical interaction between the sender and 


the receiver whenever there 1s a transfer of data. First, the data packet is sent by the 


sender through the ‘ax0’ port device. Then, the receiver receives the packet at its local 


‘axO’ port device. Then, the receiver will send an acknowledgment to the sender to allow 
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the sender to continue to send the next data packet. The data, in our experiments, is a 
series of the **’ string characters, coded as ‘2a’. All the actual data is displayed in 16- 
bytes blocks numbered starting from 0000 > 0200. At the lowest level, i.e. the KISS- 
protocol level between the PC and the TNC, it only maintains a port number and a control 
code (the format is as shown in Figure 8). In our case, as shown in Figure 9, the KISS 
level has a port numbered as ‘0’. And, the control code specifies a data type. At the next 
level, the AX.25 level, it maintains only a call-sign, a type of frame format, and a ‘pid, 
i.e. a protocol identification. In our case, the frame format is a UI frame, and, the pid is 
an IP (or, an internet protocol), and the call-signs used for source and destination stations 
are NPS1 and NPS2, consequently. The IP 1 specifies the length of the data packet, 
512-bytes long in this case. This level also specifies the IP addresses for both the source 
and destination. The UI frame is an ‘Unnumbered Information’ frame, which allows the 
frames to pass freely at the AX.25 level, since they are unnumbered. And, this allows 


the frames to be processed at higher levels i.e. the TCP/IP levels. 


Since, the UI frames are processed at a higher level than the AX.25 level, the error 
checking is done at the TCP level in our case. If there is an error, then the TCP will 
report the error and automatically request a retransmission of the error packet. And, until 
it gets an error-free packet, it will then send an acknowledgment packet to the transmitter 
to allow the next sequential packet to be sent. Figure 10 is an example of a Frame- 


Check-Sum (FCS) error detected at the TCP level. The TCP level reports a FCS error, 
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and, automatically, request a retransmission. It then waits for the same packet to be re- 


sent and correctly received before it sends an acknowledgment packet. 
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Figure 10 : An FCS Error 
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In this case the MTU is of 256-byte size, when accounted for a 40-bytes TCP/IP 
overhead, then there should be at least 216 bytes of data. But, the first data packet, as 
shown in Figure 10, contains only 215 bytes of the **’ characters. Hence, the TCP 
reports a FCS error, and automatically requests for a retransmission for the same packet. 
When the packet is re-transmitted and received correctly with 216 bytes of data, as 
shown at the TCP level of the middle packet in Figure 10, the receiver then responses 


with an acknowledge to notify the sender to proceed with the next sequential packet 
B. EXPERIMENT # 1: HALF-DUPLEX RADIO CHANNEL 


To study the data transfer behavior over a radio channel, the two nodes are set up 
as shown below. We decide to use a hardware flow control at the COM ports instead the 
software flow control because of superior performance. The hardware flow control is 
accomplished by selecting the ‘Hardware Flow Control’ option at the COM ports and 
setting the corresponding TNC’s parameters 1.e. DIR = 1 & RTS = 1 on an asynchronous 


(asy.) line. 


Katronics D4-10 
(Transceiver) 










Antenna 


Katronics Approx. 1-meter distance 


Data Engine 


Figure 11 : A Half-Duplex Radio Channel 


4] 


The TXDELAY on the TNC is set to 20 (x 10-ms unit time), i.e. 200 ms, to allow 
enough time for the radio to be fully powered up. Also, the PERSIST value is set to be 
127, which is approximately half of a chance for transmitting. At this point, the half- 
duplex radio is used, and the TNC’s parameter, ‘modem’, must be set to half duplex i.e. 


by using the TNC command ‘modem _, half’. 


The data was collected and shown in Figure 12 to 15. There are 16 files with 
various sizes ranging from 185 bytes, 336 bytes, 612 bytes, .., 1.884 Mbytes, 
consequently. Each consecutive file is roughly double the size of the previous file. There 
are four trials needed to be collected for each file due to the nature of a stochastic- 
transmitting process ( which depends on the setting PERSIST value). Then, the averages 
in both speed and time of the four trials are derived. The speed in Bytes/second and 
transfer time in seconds used in the FTP operation are reported in the system at the end of 


each file transfer operation. 


The parameter settings for Experiment # 1 dre shown in Table 1. In the table, DTS 
is ‘Data-Set-Ready'. RTS is 'Read-to-Send'. TXDELAY is 'Transmission Delay’. 
PERSIST is a ‘Persistence’ Value. SLOTTIME is a ‘Slot Time’. TXTAIL is 


‘Transmission Tail Time’. And, lastly, FULLDUP 1s ‘Full Duplex’. 
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PARAMETER SETTING 


DTS 













RTS 


TXDELAY 









PERSIST 







SLOTTIME 







TXTAIL 


FULLDUP 






Table 1 : Exp. #1 Parameter Settings 


Once all the parameters were set, the data samples for both the time transfer and 
speed versus file sizes were collected and plotted. The transfer time versus file sizes are 
shown in Figure 12 and Figure 13. And, the speed versus file sizes are shown in Figure 


14 and Figure 15. 
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Transfer Time versus File Size 
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Figure 12 : Exp. # 1 Transfer Time versus File Size 
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Figure 13 : Exp. # 1 Average Time versus File Size 
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Figure 14 : Exp. # 1 Speed versus File Size 
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Speed (Bytes/sec) in Log Scale 


Speed versus File Size 
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Figure 15 : Exp. # 1 Average Speed versus File Size 


In the plots, both the X-axis and Y-axis are in LOG scale, and the time transfer 
shows linearity with respect to increasing file sizes. This is agreed with our expectation 
because there is a fixed-size overhead associated with each data packet, and, hence, with 
more data, it should should require more time to transfer the file in a linear fashion. For 
the average speed curve, it seems that the speed curve is saturated at some specific value 
after the file size is larger than 19.2 Kbytes. By taking the average of the last six data 


samples of the speed curve, we estimated the settled speed to be 486.70 bytes/sec. 
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By observations of both the transfer time and the speed curves, the data points are 
varied in a noticeable manner. This is because the nature of the stochastic process 


affected by the setting of the PERSIST value. 
C. EXPERIMENT # 2: HARD-WIRED FULL DUPLEX 


To improve performance of data-transfer through the radio channel, the two 
TNC’s can be set to operate at a full-duplex mode. This will require two channels for the 
TNC to be able to transmit and receive at the same time. Hence, the radio must be able to 
operate at two different frequencies, one for receiving and the other for transmitting. 
However, our radio does not have such capabilities. Therefore, we emulated a full duplex 
environment for the two TNC’s by directly connecting the two TNC’s together and 
bypassing the radio transceivers. This emulation gives us a full-duplex like-radio 
channel, although we do not have a true full-duplex radio channel. The main difference 
between a real full-duplex radio channel and our ‘emulated’ full-duplex channel is the 
radio wave interference which may occur in the real channel. In our experiments, the 
interference is assumed to be minimum, since we operate in a controlled environment 1.e. 
our laboratory. Also, fading channel is assumed to be very small, since the distance 
between the two nodes is very short-1.e. approximately 1 meter. The set up for an 


emulated-radio full-duplex channel is shown in Figure 16. 


48 


PC #2 PC #1 


Directly connected DB-9 connectors 





FULL DUPLEX CHANNEL 


Approximately 1-meter distance 


Figure 16 : A Emulated-Radio Full Duplex Channel 


The connection between the two TNC’s are made directly between the two 9-pins 
DB-15 connectors attached to the two Katronics Data Engines at port # 1’s. The hard- 


wired diagram between the two connectors is shown in Figure 17. 


DB-15 Connector DB-15 Connector 


Ground Pin 9 =? cy Pin 9 Ground 





Figure 17 : TNC Hard-Wired Connections 


The parameter settings for Experiment # 2 are shown in Table 2. Notice, the only 
difference from Experiment # 1 is the FULLDUP set to 1, which enables the full-duplex 


channel between the two TNC’s. 
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PARAMETER | SETTING 


DTS 








RTS 





TxDelay 





PERSIST 









SLOTTIME 







TXTAIL 


FULLDUP 






Table 2 : Exp # 2 Parameter Settings 


Once the all the parameters were set, the data samples for both the transfer time 
and speed versus file sizes were collected and plotted. The transfer time versus file sizes 
are shown in Figure 18 and Figure 19. And, the speed versus file sizes are shown in 


Figure 20 and Figure 21. 
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Figure 18 : Exp # 2 Transfer Time versus File Size 
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Figure 19 : Exp # 2 Average Time versus File Size 
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Figure 20 : Exp. # 2 Speed versus File Size 
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Speed versus File Size 
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Figure 21 : Exp. # 2 Average Speed versus File Size 


From the time transfer and speed curves, it seems that the FTP process is 
smoother than that in Experiment # 1. This is because the channel is a hard-wired full- 
duplex channel, in which, there is very little interference compared to the true radio 
Channel. For the speed curve, it seems more clear than those in Experiment # 1 that the 
speed curve starts turning into a saturated speed at roughly 19.2-Kbytes file size. And, by 


taking the average of the last six data samples of the speed curve, the average saturated 


speed is 1344.9 Bytes/sec. 
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D. EXPERIMENT #3: ENHANCED HARD-WIRED FULL DUPLEX 


In Experiment # 2, the channel is already a full-duplex channel but without a real 
radio transmitter. Hence, there are some parameters that can be set to achieve optimal 
performance; the TXDELAY and the PERSIST value. The TXDELAY can be set to 1 
because there is no need to delay the data before transmitting for powering-up the 
transceiver, since there is no radio transmitter needed. Also, since the channel is 
relatively cleaner than that in Experiment # | due to hard-wired full-duplex environment, 
hence, the PERSIST value can be set to its maximum value (255) to maximize the chance 
for transmitting data, which increases the data rate i.e. speed. The parameter settings are 


shown in Table 3. 


Once all the parameters were set, the data samples for both the transfer time and 
speed versus file sizes were collected and plotted. The transfer time versus file sizes are 
shown in Figure 22 and Figure 23. The speed versus file sizes are shown in Figure 24 


and Figure 25. 
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PARAMETER | SETTING 


DTS 










RTS 


TxDelay 


PERSIST 


SLOTTIME 


TXTAIL 


FULLDUP 


Table 3 : Exp. # 2 Parameter Settings 
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Figure 22 : Exp. #3 Transfer Time versus File Size 
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Figure 23 : Exp. # 3 Average Time versus File Size 
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Figure 24 : Exp. #3 Speed versus File Size 
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Figure 25 : Average Speed versus File Size 


From the time transfer and speed curves for Experiment # 3, it is clear that there is 
some speed improvement when optimal parameters are used. The average speed from the 


last six data samples is 1528.25 bytes/sec. 
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E. EXPERIMENT # 4: ROUTING EFFECTS 


In additions to EXP # 2, we want to study the effects of routing when there are 
more than two nodes involved. Hence, we make some modifications and add a router, 


PC # 1, between PC # 2 and PC # 3 as shown in Figure 26. 





PC #3 FULL DUPLEX CHANNEL 
Approximately 1 ft. distance 
TNOS 
TNC (Directly connected DB-9 connectors) INC 
{KESS) {KISS) 


PC#2 


TNOS. 
RS-232 Line 


(Full-Duplex Channel) 


Figure 26 : Adding a Routing Node 


As shown in Figure 26, PC # 1 1s set up as a router between the two PC’s. The 
FTP operations are conducted between PC # 2 and PC #3. The files are transferred from 
PC #3 to PC #2. A route table is created and maintained at PC # 1 by using the TNOS’ 


‘route add’ command. 


An additional interface between PC # 2 and PC # 1 is the RS-232 line, which was 
added to the set up of EXP #2. The RS-232 line is an industry-standard physical 


interface. It is intended for communicating no more than 50 feet at 20,000 bps [7]. 
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There is an important issue in dealing with the RS-232 line, it is the selection of the flow- 
control scheme. There are two flow-control schemes used to prevent buffer overflows; 
the software flow control (XON/XOFF and ENQ/ACK) , and the hardware flow control 
(DSR, CTS, and CD) [7]. The software flow control is executed by sending a ‘STOP’ 
character back and forth to notify the device that the buffer is already full. In contrast, the 
hardware flow control simply just deactivate the line to prevent/stop buffer overflows. 
The RS-232 link in our experiments is implemented by using two 25-pin connectors. The 


connection is as shown in Figure 27. 


25-pin Submin-D 25-pin Submin-D 
Connector Connector 
| Transmit Data Pin | Data Pin 2 = Pin 2 Transmit Data 
Receive Data Pin 3 2 Se es: —_ Pin 3 Receive Data 


| Request to Send (RTS) Pin4 | to Send | Request to Send (RTS) Pin4 | Pin 4 


|_| Pin 4 Request to Send (RTS) 
Clear toSend(CTS)  PinS - || Pin 5 Clear to Send (CTS) 


a: Pin6 Data Set Ready (DSR) 


Data Set Ready (DSR) Pin6 _& 
ee =< Dre? ___Groma 


Carrier Detect (CD) Pin8 ol ae Pin8 Carrier Detect (CD) 
Data Terminal Ready Pin 20 Fa] Pin20 Data Terminal Ready 


Ring Indicator Pin 22 7 Cd Pin 22 Ring Indicator 





Figure 27 : RS-232 Line Connection 
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As seen in Figure 27, there are two lines connecting the two end nodes. Hence, 
the RS-232 interface in the above configuration is able to transmit and receive data 
simultaneously, and so, acting like a full-duplex channel. The rest of the pins, not shown 


in Figure 27, are not connected, because there is no need to utilize them in our 


experiments. 


With optimal parameters setting, another router is added between PC # 2 and PC # 
3 as described in the Experimental set-up. The data points were again collected and 
plotted. The transfer time versus file sizes are shown in Figure 28 and Figure 29. The 


speed versus file sizes are shown in Figure 30 and Figure 31. 
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Figure 28 : Exp. #4 Transfer Time versus File Size 
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Figure 29 : Exp. # 4 Average Time versus File Size 
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Figure 30 : Exp. # 4 Speed versus File Size 


65 


Speed versus File Size 
(Routing) 


Average 


Speed (Bytes/sec in Log Scale} 





0.2 0.6 2.2 9.8 41.5 186.56 529.6 1268.6 
0.4 1.2 43 20.8. 89.9 283.3 960.7 1884.5 
Size (Kbytes in Log Scale) 


Figure 31 : Exp. # 4 Average Speed versus File Size 


The average speed taken from the last six data point, in Figure 29, is 1000.2 


Bytes/sec. There is a big drop in speed due to routing, compared to previous average 


Speed curves. 
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V. DISCUSSION 


A. TIME COMPARISON 


The averages of the four curves, time transfer, are plotted and compared as shown 
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Figure 32 : Transfer Time Comparison 


Figure 32 compares the time-average curves used in each experiment. From the 
time comparison curves as shown in Figure 32, the relative performance of each curve is 
related to its own position relative to others. For an example, Curve # | (from Exp. # 1) is 
at a higher position as compared to Curve # 4 (from Exp. # 4), which means that the 
Curve # 4 has a superior performance, since it requires less time to deliver a file of the 


same Size. 


From observations of the 4 curves, it seems that they follow the same trend even 
though their shapes are a little different. Curve # 1 is a straight-line shape and different 
from others because it is the only real radio channel. The other curves show superior 
performance than Curve # 1 because they are all full-duplex channels. Also, Curve # 2, 
Curve # 3, and Curve # 4 have similar shapes due to their similarities in the experimental 
set-ups. Curve # 3 has the same shape with Curve # 2 because they both have the same 
set-up. However, Curve # 3 has a superior performance than Curve # 2 because it has an 
optimal set of parameters. In addition, Curve # 4 has a very similar shape, as compared 
to Curve # 2 and # 3, this is because Curve # 4 has most of its the set-up like of those 


curves but with an additional routing delay. 


From comparing Curve # 2, # 3, and # 4, it seems that at each region of the 
curves, they tend to follow a specific value of local slope i.e. they almost have the same 
slopes at some local range of file sizes. This local-slope phenomenal may be a result of 
the window size and/or the MTU size, used in our experiments with respect to the file 


S1Ze. 


68 


Ibe SPEED COMPARISON 


For speed comparison analysis, the average speed curves of Experiment # 1 
through Experiment # 4 are plotted in the same graph to demonstrate their relative 


performance. The plot is shown in Figure 33. 
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Figure 33 : Speed Comparison 


Figure 33 shows the speed comparison between the four experiments. In this 


case, higher performance is shown in a higher vertical position of the curve. A higher- 
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curve position indicates a faster channel. And, as expected, like those curves in Figure 

32, the performance for each curve from highest-to-lowest is Curve # 3, Curve # 2,Curve 
Curve # 4, and Curve # 1. The reasons are the same as those explained for Figure 32. In 
addition, from the observations of the curves, it is clear that, in our experiments, the full- 
duplex channels, Curve # 2, Curve # 3, and Curve # 4, are superior in performance than a 


half-duplex channel, Curve # 1. 


Also, the turning corner before saturation of each curve is close to the number of 
19.2-Kbytes file size. This number is related to our channel’s maximum capacity of 19.2 
Kbaud rate as provides by our TNC’s. Before this point on the X-axis, there is an 
increase in speed as the file size 1s increasing until it reaches the channel maximum 
capacity of 19.2 Kbaud. The speed is increased, at the region of small file size below the 
channel’s full capacity, because at those region the data is smaller than the pipe (i.e. an 
analogy for our channel capacity). Hence, the more data there is, the more the channel 
can deliver. However, once the data size is larger than our pipe, then no matter how 
large our data is we can only put certain amount of information into the pipe at one time 
because the pipe has a fixed size (i.e. as compared to our channel’s Baud rate) . Hence, it 


causes a speed saturation as shown in a flat region on each curve. 


In addition, from observing the curves it is clear that an additional routing node 
tremendously adds delay to the speed. The increase/decrease in performance, as 


compared to each other, is shown in Table 4. 


70 


EXP.#1 | EXP.#2| EXP.#3 | EXP.#4 


Speed (Bytes/sec.) 486.7 1,344.9 oes 5 1,000.2 














3,893.6 LOWeo 2. 12,226,0 8,001.6 






Speed ( Bits/sec. ) 














x 1 x 2.76 x 3.14 x 2.05 






Improvements 


(x times as Compared to Exp. # 1 ) 


Table 4 : Speed Comparison 


From analyzing Table 4, it is seen that the emulated-radio full-duplex channel as 


in Exp. # 2 and Exp. # 3 improves the speed by approximately 3 times higher than that of 


the radio half-duplex channel in Exp. #1. Also, the routing node, in Exp. # 4, causes a 
performance drop to only 2.05 times higher than that of Exp. #1. Hence, there is a 


tremendous drop in the performance due to routing. 


Our maximum performance as shown in Exp. #3 is 12.226 Kbits/sec. The rest of 


the bandwidth, i.e. 6.97 Kbits/sec., is probably consumed by the overheads, i.e. mainly 
the TCP/AIP & AX.25, used in transferring the data across the mediums. Hence, the 
overhead cost in our experiments is relatively large compared to our available 


bandwidth. 


Wi 


In a video-conferencing application as desired in our project, the implementation 
may be possible only if a very effective compression scheme can tremendously reduce 
the size of the data stream to fit our maximum capacity. It is mentioned in the study by 
[9], that a high quality compression technique may be able to compress the data to below 
1/50 the size of the original data. Assuming that this type of compression scheme is 
available and implemented with our existing system, we would be able to support a 


channel of more than 50 x 12.226 Kbits/sec. (i.e. 611 Kbits/sec.). 


With this possible maximum capacity of 611 Kbits/sec, we may be able to support 
many image-delivery implementations such as delivering a quality stilled-image in a 
reasonable time, as studies in [9], and, may be in a distance learning application as 
studied in [14]. In delivering a quality tilled-image for a medium-quality image 
resolution of the size 230,400 bytes [9], our system would delivery in about 151 


seconds, which is an acceptable time for this kind of application. 


However, for a video-conferencing type of system, time of delivery is much more 
sensitive than just delivering a stilled image. The quality of video depends on the frame 
rate , 1.e. number of frames per second (fps), showing on the display. A full broadcast 
television in North America using an NTSC standard requires about 30 fps [14]. 
However, this fps requires too much bandwidth. Hence, many compression standards 
are used to tremendously reduce the data size to fit the available bandwidth for vedio- 
conferencing type of application such as the H.221, H.230, H.261, and H.320, etc. [17]. 


Also, in the video-conferencing type of applications, an acceptable video quality may not 
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require as high fps as in a full quality video (i.e. it requires about 30 fps). The minimum 
recommendations, from the study of a distance learning type of applications [14], for the 
frame rate is 6 fps and for the resolution needed is 320x240-pixels. This application 
would require a bandwidth of 375 Kbits/sec [14]. Hence, our system with a 


compression ratio of approximately 4:1 would be enough to support such applications. 


13 





VI. CONCLUSION AND FUTURE WORKS 


In our experiments, we implemented a half-duplex radio channel and performed a 
data transfer performance study. We found out that the data rate was very low and may 
not support video-conferencing applications. Hence, improvements were made, in 
experiments # 2 and # 3, by using a emulated-radio full-duplex channel. The result was 
an increase in performance about 3 times higher than in experiment # 1. Then, the 
routing effect was studied by adding a routing node between the link, the effect was a 
decrease in performance from experiments # 2 and # 3 down to about 2 times higher than 
in experiment # 1. From looking at the data rate supported by our system, it is possible 
that, with an advanced compression technique, the system will be able to support a video- 
conferencing type of applications over a full-duplex radio channel operating under a 


NOS. 


However, before a real implementation of this type of system, there are more 
issues to be studied such as the security aspects of such a system, the integration of the 
packet-radio-networking backbone with commercial video-conferencing 
software/hardware packages. One way to improve security, within our experiences with 
the TNOS, is that we may be able to add a secure encryption/decryption scheme to the 
TNOS software. It is possible and practical to download the TNOS software source code 


from the internet site and add some security mechanisms to it before recompiling the 
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modified source code. Also, the integration of the video-conferencing to the backbone is 
possible, provided that they both support the same industrial standards such as the TCP/IP 


protocol, or etc. 
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APPENDIX A: CONFIGURATION FILES 


vy 


# autoexec.nos file for TNOS 2.20 nps2 01/14/96 
# By Narongchai Nimitbunanan 


# Specify Hostname 

# Local host's name. It 1s used only in the greeting messages 
# of the various network sservers. 

# It DOES NOT set the system's IP address. 


hostname nps2.ampr.org 


# Set the local AX.25 address 
ax25 mycall nps2 


# Set thet default local IP address 
ip address 44.01.01.02 


# User 

ax25 user nps2 

HHA Set AX25 parameters ##4HAHHT 

# AX25 protocal version 2 which uses the poll/final bits 

# This protocal is used when attempts to make new connections 
ax25 version 2 


# Number of frames that will be allowed to remain 
# unacknowledged at one time on new AX25 connections 
ax25 maxframe I 


# Poll threshold-- used to control retransmission behaviors 
# Default value is 128 
ax25 pthresh 128 


# Packet lenght -- if the I-field (Information field) 1s greater than this, then 
# it will be fragmented at the ax25 level. 

# This parameter should be less than or equal to the MTU size 

# ax25 paclen 256 


#f-------- > Double MTU size 
ax25 paclen 512 


# Number of times trying to establish a connection. 
axe Tetnles 15 


= Set the INITIAL value of roundtrip time in milliseconds when 
= anew connection Is established. 
ep Oo ager 018 
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# Set the AX25 idle ‘keep alive’ timer in millisec. 
ax25 t3 60000 


# Set the AX25 link ‘redundancy’ timer in sec. 
ax25 t4 1800 


# Set timer type for retransmission and recovery 
ax25 timertype linear 


# Set the number of byte that can be pending on an AX25 recieve queue 
# beyond which I-frame will be answered with RNR (Reciever Not Ready) 
ax25 window 2048 


# Set the AX25 retransmission “backoff™ limit for each successive 
# transmission to prevent ‘congestive collapse’ on a loaded channel. 
ax25 blimit 5 


ax25 maxwait 9000 


# Set the text and time interval in seconds between broadcasts. 

# Text 

# ax25 bctext “Testing Beta release 01/15/97, TNOS/DOS version 2.20" 
# Time interval 

# ax25 bcinterval 30 


# Standard PC asychronous interface (com port) 

# Using com2 address Ox2f8, intrp. request 3, ax25 protocal 
#, anda kiss TNC, MTU its 256 bytes 

# By defaults IP datagrams are sent in UI frame 


# COMI -- This 1s a modem (mod0O) in NPS2 
#attach asy Ox3f8 4 slip modO 1024 256 19200 


#COM2 

# attach asy Ox2f8 3 ax25 axO 1024 256 19200 

#-------- > COM2 with double Buffer Size (2048) & Double MTU (512) 
#attach asy Ox2f8 3 ax25 axO 1024 256 19200 

attach asy Ox2f8 3 ax25 ax0 2048 512 19200 


# Serial Line Internet Protocol on COM 2 
#attach asy Ox2f8 3 slip axO 2048 512 19200 


# Set the interface description to the strings specified 
ifconfig axO description "440 MHz-- 19200 baud, TCP/IP network, D4-10 transiever" 
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#----- Attach an Ethernet Interface --> enO, txqlen = 8, mtu = 1500 
# attach packet FxF00 ethernet 8 1500 
# ifconfig enO ipaddress 131.120.20.166 


# Add a permanent entry in to the look-up table 

# address resolution protocol (arp) maps the IP address into 
# the subnet(link) address to the specific IP address 

arp add 44.01.01.01 ax25 npsi ax0 

arp add 44.01.01.03 ax25 nps3 ax0 


# Ethernet arp 
# arp add 131.120.20.165 ether nps!1 enO 


# Add the default entry into the routing table 
route add default ax0 44.01.01.01 

# route add nps2 ax0 44.01.01.02 

#route add nps3 ax0 44.01.01.03 

# Ethernet router 

# route add nps11 enO 131.120.20.165 


# Invoke a device-specific control routine. On a KISS TNC interface, 
# this sends control packets to the TNC 

# Enable the hardware control 

param ax0 DTR 1 

param ax0 RTS 1 

trace axO 211 


# Domain name server 


domain dns on # Turn on 
domain ttl 7200 # Time-to-live of domain name Server in sec. 
domain addserver 44.01.01.01  #nps1 is also a domain name server--hostid 
domain maxwait 60000 # Set time-out for the dns 
domain suffix ampr.org. # Default domain name suffix 
domain translate off # Turn off the translation from IP address 

# dot notation into a symbolic name 
domain subnet off # Translate subnet IP address and broadcast addresses 
domain verbose off # Flag controlling return of a full name 
domain update on # Uodate domain file 
domain cache size 200 # Local memory cache size 
domain cache clean on # Set the discard of expired resource records 
domain cache wait 600 # Set the interval in sec. to wait for additional 


# activity before updating the domain.txt file 


# TCP Global parameters 
tcp irtt 1500 

tcp window 4096 

tcp mss 966 

tcp timer linear 

tcp syndata on 


tcp maxwait 60000 
tcp trace on # Tum on trace for tcp level 


ifconfig encap mtu 576 


# Global IP parameters 
ip tt] 255 


# This parameter is not used for TNOS v. 2.21 
# 1p encapnew on 


# Server 
start ax25 


# Converse 
start convers 3600 


f winger Server 
start finger 


we P 
start ftp 


# telnet 
start telnet 


# Start all kinds of servers 
#start info 

#Start news 

#Start remote 

#start smtp 

#Start ttylink 

#Start tutor 


# Smtp parameters 
#smtp timer 600 
#Smtp max 4 
#Smtp trace 0 
#Smtp usemx on 
#Smtp batch on 
#Smtp header on 
#smtp sendlzw on 
#smtp reclzw on 
#smtp bidcheck on 
#smtp notify on 
#smtp quiet off 
=#smtp t4 600 


8 | 


# FTP parameters 
ftype i - 

ftptdisc 600 
ftpmaxclients 2 


# Converse parameters 

conv mycall nps2 

conv hostname nps2 

conv interface ax0 

conv header on 

conv hmaxgq 8192 

conv umaxq 1024 

conv t4 600 

conv maxwait 120 

conv motd "This 1s the CONVERS MODE" 
conv sysinfo "New TNOS server nps2.ampr.org" 


# Switch the TNC into the KISS mode 
#comm axO " " 

#comm axO “int kiss" 

#comm axO "reset" 


# TxDelay 
# param axO | 20 
#param axQ | | 


# Persist 0 --> 255 
# param axQ 2 127 
#param axQ 2 255 


#param ax0 3 10 
#param ax0 4 0 


# Half-Duplex 
# param axO0 5 0 
# Full-Duplex 
#param axO 5 | 


# Time measurement in sec. 
isat on 


# Recoding for telnet 
record on 


“” 
'S) 


# This file is created by Nimit... as a test file 
# 23 Jan 1997 


# Anonymous login requires no password 
guest /tnosz] 7 


# Test 

GNOTICE ***** 

# After the first run the password ‘nimit' is hashed to be 

# the ‘number code’ below and re write back to the replace the 
# given password below 

# Permission 7 is read(1) + write(2) + delete(4) = 7 


nps1 46a9c5c3a3a021954125a6145cc05350 /tnos21 7 
nps3 f£3fd23386703a8d550c8 lbad8ef7ebf9 /tnos21 7 
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# This is a domain.txt file. 
# This file translates the CALLSIGN into IP addresses 
# A means ‘Address’ 


nps3.ampr.org. IN A 44.1.1.3 

npsl.ampr.org. IN A 44.1.1.1 
nps2.ampr.org. IN A 44.1.1.2 
nps11.ampr.org. IN A 134126.20,165 
nps22.ampr.org. IN A 131.120.20.166 


APPENDIX B: COLLECTED DATA POINTS 
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EXP. #4 


File Size in various scales Time (SEC.) Speed 9bytes/Sec.0 
Bytes Kbytes !0g_610 log b2 tnal # 1 tral#2 tnal¥3 tnal#4 Sum = avg. T#1 T#2 T#3 T#4 sum avg 
185 0.2 -0.7 -2.4 1 1 1 1 4 1 165 185 159 176 685 171.25 
386 0.4 -0.4 -1.4 1 1 1 1 4 1 278 266 282 267 1093 273.25 
612 0.6 -0.2 0.7 2 2 2 2 8 2 258 247 253 221 979 " 244.75 
1222 1.2 0.1 0.3 3 3 7 2 {SoS 401 394 154 419 1368 342 
2460 2.5 0.4 1.3 75 4 7 4 90 22.5 32. 515 334 532 1413 353.25 
4900 4.9 O7 de | 7d 7 22 7 43 10.75 682 692 213 654 2241- 560.25 
9780 9.8 1.0 3.3 12 29 42 27 80 20 755 328 753 354 2190 547.5 
20759 20.8 Ves 4.4 34 24 41 40 139 34.75 595 845 SO1 424 2365 591.25 
41518 41.5 1.6 5.4 51 53 53 128 285 71.25 803 774 778 322 2677 669.25 
89869 89.9 2.0 6.5 141 142 228 141 652 163 634 632 393 636 2295 Sia75 
186S65 186.6 2.3 7.5 391 419 516 395 1721 430.3 476 444 361 471 1752 438 
283261 283.3 25 8.1 444 584 §47 686 2261 S65.3 637 484 S17 421 2059 514.75 
529601 §29.6 2.7 9.0 1010 810 937 975 3732 933 524 653 S65 542 2284 571 
960696 960.7 3.0 9.9 2062 1423. 2252 2801 8538 2135 465 674 426 342 1907 476.75 
1268621 1268.6 3.1 10.3 2331 3252 2988 1944 10515 2629 $44 390 424 652 2010 $02.5 
1884471 1884.5 3.3 10.9 3493 4951 3808 7108 19360 4840 S39 380 494 256 1669 417.25 
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Bytes 


File Size in various scales 
Kbytes log 610 


0.2 

0.4 
0.6 

ie 

2.5 
4.9 
9.8 
20.8 
41.5 
89.9 
186.6 
283.3 
329.6 
960.7 
1268.6 
1884.5 


4 


0.7 
0.4 
0.2 
0.1 
0.4 
0.7 
1.0 
cee) 
1.6 
2.0 
2.3 
2.5 
2.7 
3.0 
3.1 
3.3 


log _b2 


-2.4 
-1.4 
0.7 
0.3 
1.3 
2.3 
3.3 
4.4 
5.4 
6.5 
75 
8.1 
9.0 
9.9 
10.3 
10.9 


trial# 4 


EXP-#4 


Time (SEC.) 
trial #2 


n & |W AI —- — 


10 
17 
31 
65 
134 
200 
378 
675 
894 
1323 


trial #3 


uw OM &® WA + = 


WwW a 
—_ 


65 
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trial#4 


Sum 


avg. 


Twi 


Speed bytes/Sec. 
T#2 T#3 T#4 


196 
271 
272 
406 
550 
797 
1028 
1207 
1307 
1370 
1391 
1431 
1422 
1364 
1364 
1420 


197 
27s 
26e 
441 
=i) 
670 
1029 
1192 
1308 
1368 
1403 
1409 
1340 
1420 
1423 
1425 


sum 


718 
1109 
1052 
1637 
2108 
2919 
3840 
4622 
9042 
3242 
5293 
3439 
$339 
5385 
3382 
$441 


aa 


179.5 
277.25 
263 
409.25 
327 
729.75 
860 
11533 
1260.5 
1310.5 
1323.25 
1359.75 
1334.75 
1346.25 
1345.5 
1360.25 


Bytes 


185 

3686 

6i2 
1222 
2460 
4900 
9780 
20759 
41516 
89669 
186565 
283261 
529601 
960696 
1268621 
1884471 


File Size in various scales 


Kbytes log _b10 


415 
89.9 
186.6 
283.3 
529.6 
960.7 
1268.6 
1884.5 


0.7 
0.4 
0.2 
0.1 
0.4 
0.7 
1.0 
13 
1.6 
2.0 
23 
2.5 
27 
3.0 
aA 
a3 


log_b2 


-2.4 
-1.4 
0.7 
0.3 
1.3 
2.3 
3.3 
4.4 
5.4 
6.5 
75 
8.1 
9.0 
9.9 
10.3 
10.9 


EXP. #3 


trial # 1 


Time (SEC.) 
trial#2 


tial#3 


a ~~ 


—_ 
oonw = = 
REREZS 
& NY W = 


trial# 4 


Sum 


avg. 


T#1 


Speed bytes/Sec. 
T#2 T#3 T#4 


sum 


avg 


272.75 
378.75 
389.75 
345.5 
7235 
994.25 
1200.5 
1357.25 
1464.75 
1484.25 
1523 
1537.75 
1521.25 
1533.75 
1521.25 
1532.5 


ROUTING Full-Duplex Radio Simulated Link 
File Size in various scales Time (SEC.) Speed bytes/Sec 

Bytes Kbytes A Index T#1 T#2 T#3 T#4 Sum = avg Index T#i T#2 T#3 THe sum avg 
185 0.185 1) 1 i 1 1 4 1 2 191 178 167 1&4 720 180 
386 0.386 2.) 1 1 1 1 4 1 2) 89 280 292 22 1144 286 
612 0.612 a5) 2 2 2 2 8 2 3%) 270 4230 273 «270 = 61043 260.75 
1222 1.222 4.) 3 3 3 3 12 | 4) 392 353 396 352 1493 373.25 
2460 2.46 ep, S $ & tS, 20 S 2)q)] 467 461 467 462 18587 464.25 
4900 4.9 SP) Z 7 7 7 28 7 6.) 675 668 666 669 2678 669.5 
9780 9.78 fhop, 12 WZ 12 12 48 12 7a) 802 797 802 801 3202 800.5 
207389 20.759 8.) 22 22 22 22 88 22 &) 923 924 912 922 3681 920.25 
41518 41.518 9.) 42 42 42 42 168 42 9) 983 976 983 9&2 3924 981 
89869 89.869 10.) 88 88 8&8 88 352 88 10.) 1016 1020 1016 1017 4069 1017.25 
186865 186.565 Wile 226 196 184 191 7937 199.3 wad} 822 949 1011 975 3757 939.25 
283261 283.261 12.) 272 272 288 278 1110 277.5 12.) 1040 1038 980 1018 4076 1019 
$29601 $29.601 133) $19 $29 $28 $17 2093 $233 13.) 1019 1000 1002 1023 4044 1011 
960696 960.696 14.) 942 965 956 943 3806 951.5 14.) 1019 994 1004 1018 4035 1008.75 
1268621 1268.621 18.) 1249 1245 1250 1257 $001 1250 Se) 10158 1018 1014 1008 4055 1O13e%0 
1884471 1884.471 16.) 1862 1875 1865 1862 7464 1866 16.) 1012 1004 1010 1012 4038 1009.5 
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Bytes 


185 
365 
612 
1222 
2460 
4900 
9780 
20759 
41518 
89869 
186565 
283261 
529601 
960696 
1268621 
1884471 


File Size in various scales 


Kbytes 


20.8 
41.5 
89.9 
186.6 
283.3 
529.6 
960.7 
1268.6 
1884.5 


log_b10 


3.3 


log _b2 


24 
“14 
7 7 
0.3 
Wes} 
23 
as 
4.4 
5.4 
SiS 
75 
8.1 
9.0 
9.9 
1653 
10.9 


Comparison 


Comp.:ison 


Time avg 
#1 #2 #3 #4 
i 1 1 1 
‘ 1 1 
2 2 1 2 
a;7s 2.49 2 3 
22> 4 3 S 
10:72 6.25 4 7 
20 9.5 8 72 
ga:75 7.75 15 22 
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tives 
273 25 
244 75 
342 
353.25 
560.25 
547.5 
$91.25 
669.25 
S737 
438 
514.75 
Sa 
476.75 
59 Pa 
417.25 


Comparnson 
Speed Avg 
#2 


1795 
277.25 
263 
409.25 
527 
729.75 
960 
11555 
1260.5 
131635 
1323725 
1359.75 
1334.75 
1346.25 
1345.5 
1360.25 


#3 


212.15 
Si6:10 
389.75 
545.5 
725 
994.25 
1200.5 
157.29 
1464.75 
1484.25 
1$23 
1537.70 
1521-25 
i2c0.70 
1521.25 
1592.5 


#S 


180 
266 
260.75 
373.25 
464.25 
669.5 
800.5 
320,25 
981 
1017.25 
$39.25 
1019 
1011 
1008.75 
1013.75 
1009.5 


10. 


11. 
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